@derfs Without knowing anything about this rhe log mentioning Spiral.blanker looks like to me a screen saver starting. So likely to OS still works but some parts are frozen like graphics output waiting for some event to happen that does not happen such as an IRQ which probably happens on real hardware but somehow missed on emulation. Without knowing more about this it would be hard to find out. If the same can be reproduced with Linux that may at least give as some log messages to point some direction because the AmigaOS logs don't seem to have any error that could help. I may also be wrong with the theory that it's caused by a missed interrupt but that seems to be a plausible reason but we would need some help from somebody who can debug AmigaOS and find out what is happening. I don't have access to AmigaOS source and don't know what it does so I can't really debug it.
Although I wonder if the network problem reported before is the same issue. Can that be reproduced some way so I can try to look at it?
The boingball blanker will freeze my X5000. So better disable all screen blankers with the sm501 driver and then try again to see if the crashed keep appearing.
@geennaam I guess it froze much before any screen blanker started so it should not be related to that. Maybe it would freeze faster if you use more PCI devices simultanously such as network, sound and a usb mouse (add -device usb-mouse) and move it around while playing sound and see if that freezes or also using network. The gfx card may use interrupts that the emulated sm501 doesn't so maybe that's why we get freezes with a passed through card but I still don't know so just want to verify this theory because I don't have any better one at the moment.
In the ranger screenshots I posted after a freeze, the irq of the gfx card was different from the other devices. This doesn’t mean it’s not an irq issue though!
The boingball blanker will freeze my X5000. So better disable all screen blankers with the sm501 driver and then try again to see if the crashed keep appearing.
I don't think it's the sm501/502 and the screensavers, I just tested it with the BoinBall screensaver too. It can be configured without problems but does not switch to full screen. The system remains stable.
However, to be able to exclude as many error sources as possible, you can of course disable everything that somehow accesses the video output.
Edit:All other screensavers work without problems.
Edited by Maijestro on 2023/7/8 20:04:48 Edited by Maijestro on 2023/7/8 20:08:23
I’m out now but tomorrow I can easily reproduce the network hang on-demand. The debug log doesn’t give any clues though. I’ve not read back through to see if there’s anything else I can do in terms of log or anything
We saw freeze on QEMU with MorphOS before when multiple PCI devices were used and in that case the cause was quite clear because MorphOS uses an ancient feature of ISA PIC to use level sensitive mode that wasn't emulated. This was fixed in QEMU 8.0 but nothing else uses that and other OSes including AmigaOS and Linux use the default edge sensitive mode. There's some info on this topic and the baclground in the intro part of this book chapter https://www.oreilly.com/library/view/l ... s/0596000081/ch09s06.html so maybe there's something with emulating interrupts or this is something that would also happen on real hardware but for some reason less often to cause a problem. I don't know how to debug or improve this, the only thing in this area I had is a patch here: cd0b323bb88df202e36014f950c0eb ... 24.git.balaton@eik.bme.hu" rel="external" title="">cd0b323bb88df202e36014f950c0eb ... 24.git.balaton@eik.bme.hu" title="https://patchew.org/QEMU/cover.1677628524.git.balaton@eik.bme.hu/cd0b323bb88df202e36014f950c0eb13a9fafd54.1677628524.git.balaton@eik.bme.hu/#cd0b323bb88df202e36014f950c0eb ... 24.git.balaton@eik.bme.hu" rel="external">https://patchew.org/QEMU/cover.1677628 ... 24.git.balaton@eik.bme.hu that tried to make sure there's always an interrupt triggered when needed but this was replaced with implementing level sensitive mode so this patch wasn't needed any more but maybe worth a try to see if it makes any difference for this (likely not) but I have nothing better at the moment.
To get futther we should find out what the OS is waiting for when it appears frozen. Is there a way to get some debug info from AmigaOS when a hang happens? Like triggering some dump of all tasks or otherwise find out what is it doing?
To get further, we should find out what the OS is waiting for when it appears frozen. Is there a way to get some debug info from AmigaOS when a hang happens? Like triggering some dump of all tasks, or otherwise find out what is it doing?
Dunno if you know about or not (probably yes, but just in case):
Short version: When amigaos4 crash/freeze/hang, it dumps register state, taks, stack trace, and co to serial, and, if you're lucky and intuition didn't die, a copy showed visually on workbench via GrimReaper utility. But often GrimRepear can't be spawn due died inutition/etc, so then you check serial.
Long version: amigaos4 do have 2 reapers : one user-friendly GrimReaper (just utility) and second one is "real" kernel's reaper, which triggers when hang/freeze/crash happens. And this is the reaper which call this GrimReaper. What it means, that when you have hardcore crash, and intuition, dos, and stuff die, kernel's reaper can't spawn grimreaper, and everything looks like hangs, while is not, and real, kernel's reaper spawn necessary info to serial. Sometime issue is so hardcore that even kernel's reaper can't throw a shit, in that case, devs increase "debug level" saying to the kernel's reaper to dump more info.
In other words, it works like this : if you OS4 freeze/hang, and no GR spawn, and you still need debug info with all those regs,stack,processes,tasks,etc, then, setup OS4 to throw output to serial, add "munge" option just in case and set debug level to 1 or to 3. Then try again, if nothing at all on serial, then increase debug level to 5. And so on.
I wrote years ago article about all that if you in interest to dig in a bit more in:
I have not had a crash for 20 minutes now, which beats the 0-30 seconds i was getting before.
The reason is that i used the sm502 device on its own, created an Amiga monitor file for my Radeon (Radeon HD PITCAIN) and changed interrupts to false/off/unticked (depending on where you do it).
The bad news is that as soon as i add a network card, the hard crashes come back. Looks like it is an IRQ issue.
Ranger output with no network card
... only showing the relevant entries
00.0C.01 IDE Controller Interrupt: Line 0x0E Pin: A Number 30
00.0C.02 USB UHCI Interrupt: Line 0x09 Pin: D Number 25
00.0C.03 USB UHCI Interrupt: Line 0x09 Pin: D Number 25
00.0C.05 Audio Device Interrupt: Line 0x09 Pin: C Number 25
00.0C.06 Communications Device Interrupt: Line 0x09 Pin: C Number 25
01.01.00 VGA Controller Interrupt: Line 0x09 Pin: A Number 25
qemu info pci
(qemu) info pci
Bus 0, device 0, function 0:
Host bridge: PCI device 11ab:6460
PCI subsystem 1af4:1100
id ""
Bus 0, device 1, function 0:
Display controller: PCI device 1234:1111
PCI subsystem 1af4:1100
BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x00fffffe].
BAR2: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
id ""
Bus 0, device 12, function 0:
ISA bridge: PCI device 1106:8231
PCI subsystem 1af4:1100
id ""
Bus 0, device 12, function 1:
IDE controller: PCI device 1106:0571
PCI subsystem 1af4:1100
IRQ 14, pin A
BAR0: I/O at 0x1000 [0x1007].
BAR1: I/O at 0x100c [0x100f].
BAR2: I/O at 0x1010 [0x1017].
BAR3: I/O at 0x101c [0x101f].
BAR4: I/O at 0x1020 [0x102f].
id ""
Bus 0, device 12, function 2:
USB controller: PCI device 1106:3038
PCI subsystem 1af4:1100
IRQ 9, pin D
BAR4: I/O at 0x1040 [0x105f].
id ""
Bus 0, device 12, function 3:
USB controller: PCI device 1106:3038
PCI subsystem 1af4:1100
IRQ 9, pin D
BAR4: I/O at 0x1060 [0x107f].
id ""
Bus 0, device 12, function 4:
Bridge: PCI device 1106:8235
PCI subsystem 1af4:1100
id ""
Bus 0, device 12, function 5:
Audio controller: PCI device 1106:3058
PCI subsystem 1af4:1100
IRQ 9, pin C
BAR0: I/O at 0xffffffffffffffff [0x00fe].
BAR1: I/O at 0xffffffffffffffff [0x0002].
BAR2: I/O at 0xffffffffffffffff [0x0002].
id ""
Bus 0, device 12, function 6:
Class 1920: PCI device 1106:3068
PCI subsystem 1af4:1100
IRQ 9, pin C
id ""
Bus 0, device 0, function 0:
Host bridge: PCI device 11ab:6460
PCI subsystem 1af4:1100
id ""
Bus 0, device 1, function 0:
VGA controller: PCI device 1002:6811
PCI subsystem 1462:3050
IRQ 9, pin A
BAR0: 64 bit prefetchable memory at 0xc0000000 [0xcfffffff].
BAR2: 64 bit memory at 0xd0000000 [0xd003ffff].
BAR4: I/O at 0x1000 [0x10ff].
BAR6: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
id ""
Bus 0, device 2, function 0:
Audio controller: PCI device 1002:aab0
PCI subsystem 1462:aab0
IRQ 9, pin B
BAR0: 64 bit memory at 0xffffffffffffffff [0x00003ffe].
id ""
(qemu)
@derfs At least we have something to start from but it's not clear what the network card IEQ would be shared with if you disabled the gfx card IRQ. Do you use USB or sound or just the network when it freezes? Does the same happen with Linux? Can you try to reproduce it wirh Linux too and see if that logs something. Maybe also check info pic output in QEMU monitor when it hangs.
@kas1e (Grim)Reaper only displays information if something crashes, but for example if there is an endless loop in an interrupt or exception handler, which have higher priorities than tasks, the system is dead and you don't get anything. There are some serial debugging options in the kernel (probably kernel.debug only), incl. using a remote gdb, but it has to be started before a freeze, you can't do anything after.
@derfs Everything, except for PATA, using interrupt 25 wont work. Funnily enough sg2's PATA/SATA/SCSI drivers do support shared interrupts, but it gets an own one (30), while probably not all other drivers using the same interrupt 25 support shared interrupts...
@balaton Quote:
At least we have something to start from but it's not clear what the network card IEQ would be shared with if you disabled the gfx card IRQ
Disabling interrupts in the monitor driver only disables using an interrupt handler in the gfx driver (busy waiting for async gfx operation completion instead), but it doesn't disable the interrupt itself. If it would disable interrupt 25 completely it would immediately kill USB, network and audio as well.
Quote:
the cause was quite clear because MorphOS uses an ancient feature of ISA PIC to use level sensitive mode that wasn't emulated.
AmigaOS 4.x supports both level and edge interrupts. The default should be edge, but some drivers might change it to and use level interrupts instead.
It's useful if it is offline and to get it online. Just open up Devs/NetInterfaces and double click the interface. But the icon is messed up and none actually have the right tool type to put it on line.
The wizard always sets the Dialer in the tooltype regardless of connection so it's rather ignorant. In all cases it needs to use AddNetInterface. So that should be set to launch the interface.
Then in the shell i just do "echo aaaa > /dev/ttyS0" , and nothing :(
I might know what that is. But if you are root in the installer it shouldn't be the case. I always had trouble with serial because I found you need to be root to use serial devices. No wonder I could never get it working on Linux but with an old program on OSX it just worked. Your user needs to be part of the tty group. You need tty access. Lol.
Or maybe:
sudo echo aaaa > /dev/ttyS0
...
Quote:
In other words, it works like this : if you OS4 freeze/hang, and no GR spawn, and you still need debug info
That reminds me. Must make a report about this. The GR is ignorant to what is a task or interrupt. It doesn't know the difference. This will make it difficult to debug interrupt code that is crashing. It will blame the current task. If a crash log of a repeatable crash contains random tasks crashing in the same code it's likely an interrupt. They need to fix it. Don't know how they debugged device drivers when the crash logger doesn't know what an interrupt is. They need a way to insert an NT_INTERRUPT in the ThisTask field of Exec or something.
The reason is that i used the sm502 device on its own, created an Amiga monitor file for my Radeon (Radeon HD PITCAIN) and changed interrupts to false/off/unticked (depending on where you do it).
That's interesting. On my X1000 OS4.1 doesn't like my particular R7 250 and started freezing on Workbench after boot. I disabled interrupts and it became more stable.
Maybe there's something wrong with irq disabling/enabling. Passthrough IRQs being ~"delivered"/~"executed" by qemu even when guest OS did do those things it does, to set the computer/hw/irq controller/whatever to a state which prevents that (on real hw).
@joerg First of all what is IRQ 25? There are only 16 ISA interrupts in pegasos2 (it has no APIC I think only the two ISA PICs) and also Ranger lists IRQ line 0x9 so it's IRQ 9 that's shared between all PCI devices and it is how that's done on real hardware as well as you can see from logs ported here from real hardware. So this is supposed to work somwhow and sharing the interrupts is not the problem unless the rtl8139 driver has some problem with that which is what I start to suspect now. Maybe it was just not tested on real hardware because the pegasos2 has more than enough on board ethernet ports for a desktop. So we could test two things:
Could those who run emulation besides testing the same with Linux as I've asked above please try to test AmigaOS without network card for a while to see if the freeze happens that way too? You can also try using -device ES1370 for sound instead of via-ac97. This uses the same IRQ but different driver so maybe gets us closer the where the problem could be.
Those with real pegasos2 do you have an rtl8139 card to test that this at least works well on real hardware and not a problem with the driver?
Maybe there's something wrong with irq disabling/enabling. Passthrough IRQs being ~"delivered"/~"executed" by qemu even when guest OS did do those things it does, to set the computer/hw/irq controller/whatever to a state which prevents that (on real hw).
I don't think that's likely because the pass thorugh is handled by Linux and QEMU and works with other emulated machines so I don't think there's a bug there. A bug is more likely within pegasos2 emulation that I wrote or in guest code but there isn't much in pagasos2 emulation relating this although the IRQ delivery in pegasos2 is a bit confusing as PCI interrupts are connected to both VT8231 and Marvell discovery and both of these can be programmed to raise a CPU interrupt. I think we emulate both as some guests use one way and others the other and beginning of this year before QEMU 8.0 we found that AmigaOS seems to use the VT8231 so maybe something is not emulated there correctly but it would be hard to debug because one could enable traces for IRQ state changes but since there are millions in a run it would be impossible to find anything in that unless we know what to look for. So first should locate the problem a bit more to be able to pinpoint what to check further.
I was going to have another attempt to install Linux into a VM today to see if I get the same crashes there or not. The install failed yesterday for some reason but I was in a hurry.
As for OS4 if I have sound and network, I can avoid crashes by just not using the network and ensuring system sounds are turned off. If you don’t turn off system sounds then you don’t even get all the way through the startup sound before the os hangs. No output in serial debug.
I did also already try the es sound card with no change. The only thing is, I was not able to remove the ac97 device. I believe because it is built in to pegasos2 emulated machine? I’m certainly not explicitly adding it.
A bunch of things to work on, and will report back if I find anything conclusive. All I have so far is that if I didn’t use sound or network, the devices being there didn’t seem to be a problem. I did get a guru crash when starting codebench but I think that has some collaboration tool that runs in the background and has probably gone out to the internet and caused a network crash? Guessing there though.
MartinW wrote: As for OS4 if I have sound and network, I can avoid crashes by just not using the network and ensuring system sounds are turned off. If you don’t turn off system sounds then you don’t even get all the way through the startup sound before the os hangs. No output in serial debug.
This error is known to me and that was before Qemu 8.0, as soon as AmigaOs4.1 booted up and tried to play the startup sound, the system failed completely.
@balaton then adjusted the via-ac97 emulation and then it worked, maybe there is a connection to the whole thing here.
To ensure that nothing accesses the via-ac97 emulation (driver) under AmigaOs4.1 you can temporarily disable or rename this driver.
Sys:Devs/AHI/via-ac97.audio e.g. to via-ac97.audioBackUp
Exactly the same could be done with the rtl8139 which is located in:
Sys:Devs/Networks/
As soon as you need these drivers again you can quickly reactivate them.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
