Ideally AmigaOS should set up the hardware the way it likes but if this is something done by the pegasso2 firmware we can emulate that when not using firmware (either in QEMU or BBoot).
The AmigaOS kernel doesn't configure any hardware but uses whatever the firmware has set up. For example on the AmigaOne you can switch between level and edge triggered IRQs in the U-Boot menu. I don't remember which one works, but with the other option you get a lot of problems on a real AmigaOne.
Most AmigaOS hardware drivers depend on the configuration done by the firmware as well and don't configure their hardware themselves, the gfx driver for Radeon R100/R200 cards (ATIRadeon.chip, not Hans' RadeonHD/RX drivers) even only works if the x86 BIOS of the gfx card was executed by the x86 emulator of the firmware.
I still have a peg2, although it's mostly collecting dust since upgrading to X5000 & Tabor.
I've had it for a long time and the drivers works fine afaik. There is ONE problem tough, maybe it's driver related? When using warp3d there can sometimes be heard a beeping sound from the soundcard.
balaton wrote:@joerg @sailor has one too but she's probably too busy with her new A1222+ now. I think @flash had one too but maybe ran MorphOS on it more.
Of course, I can test Pegasos 2. Let me know, what is need. Only just now I have inside Radeon 9800 Pro, i.e. I can test everything except gfx acceleration. I have also Radeon 9000 Pro for AmigaOS 3D somewhere, so I can change it. Btw I am busy also with Sam460LE, an planning Pegasos 2 CPU swap. And of course gardening - spring is starting.
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
I have a Peg2 (latest rev with 2gb ram) and an Ati 9250 (maybe also a sb live for audio) It’s in multi boot with os4, mos and debian. Let me know if I can help.
Your logs don't make sense to me (although I don't know how it works nor how it should work so I'm only trying to make some guesses). I only see updates in the master PIC but IRQ9 which is used by all PCI and on-board devices on pegasos2 is on the slave PIC so where are the logs from that? Maybe something masked out IRQ2 on the master and hasn't reenabled it so the slave interrupts can no longer be raised? I don't know what are the bits in IMR (and too lazy to look it up now) but it seems to have more bits set when you get the problem.
I don't fully understand how the emulator works. The logs are basically recording calls to specific functions that I manually added printf() statements too (e.g., pegasos2_pci_irq()). Using the general trace function floods the logs with too much info.
Quote:
If you've traced that the interrupt reaches cpu_interrupt() then that should come back as an exception in qemu/target/ppc/excp_helper.c and it's not very likely to be lost there. You can get a log of all exceptions with -d int but it's usually too much logs to be useful. Are you sure the interrupts you see are from your PCI device and not from some other device?
I filtered out everything except for the interrupts on IRQ 9 (not easy, as the interrupt numbers used in various parts don't match. I'll check out excp_helper.c, to see if I can find something there.
I don't know what the IMR and IRR registers are supposed to contain. Likewise, I currently have no idea how the OS can check what triggered PPC6xx_INPUT_INT.
I'm also still wondering if interrupts are level triggered, and if so, is it being emulated correctly (and how could I check that). One of the last things in the log before interrupts stop working, are the virtio GPU sending three interrupts in short succession (virtio_pci_notify()) with only one interrupt being sent. However, that happened multiple times without killing the interrupts, so that alone isn't enough to cause it to fall over.
There is ONE problem tough, maybe it's driver related? When using warp3d there can sometimes be heard a beeping sound from the soundcard.
That used to be blamed on the graphics drivers. However, it now looks like the problem was how audio data was fed to the sound card. Most AHI drivers push the audio data to the sound card using the CPU. If that doesn't happen fast enough (i.e., the audio task doesn't get to run often enough), then the sound card's FIFO buffer goes empty, and you get a stutter.
IIRC, Geennaam's sound driver(s) use interrupts to pull sound data to the card. The sound card sends an interrupt when it's got enough free space, and the interrupt copies more audio data into the FIFO buffer. This method doesn't rely on an audio thread getting to run frequently enough, so it's more immune to stuttering.
@all It sounds like actual Pegasos-II users haven't noticed interrupts failing, and causing the machine to stop responding...
It sounds like actual Pegasos-II users haven't noticed interrupts failing, and causing the machine to stop responding...
That does not mean the bug is in emulation though. There could be several reasons why real machine users did not get it. E.g. they may not be using rtl8139 network card but likely the on board ethernet ports. (Since that rtl8139 driver is known to freeze sometimes I'd susepct it first. Do you also get the issue without -device rtl8139?) Also QEMU does not simulate the machine just emulates it close enough but timings can be different so if things are slower on real machine that a race condition does not happen in practice that does not mean the race condition is not there and could happen on QEMU where interrupts could be faster. It's also possible that something is different in IRQ handling than the real machine but unless you can find out that from the AmigaOS side it's not likely we can find it in QEMU. So you should find a way to get logs about IRQs on AmigaOS.
You said interrupt handlers are in a list so you could add a handler as the first element that always returns false but logs the interrupt, then you should see when the handler chain is called. If your driver later in the chain does not get an interrupt but you get the log from the first handler in the chain then something inbetween swallows the interrupt.
I never tested rtl8139, only rtl8169 and this not works for me, even if worked in AmigaOne XE. I was some years ago, so I am not remember if it freezes or just not working.
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
Maybe nobody does as it's quite big. But usually it's only needed to know the parts you care about. Interrupts in QEMU are just callback functions that get called. At the bottom the device emulation sets the interrupt which calls in the interrupt controller model (in this case qemu/hw/intc/i8259.c) that then eventually calls the CPU model's interrupt handler. On pegasos2 the i8259 PICs are embedded in the VIA VI8231 (modelled in qemu/hw/isa/vt82c686.c) where the PCI interrupts are also connected. The VT8231 has an output interrupt pin which is connected to a GPIO pin of the MV64361 north bridge and the interrupt output of the MV64361 is connected to the CPU interrupt input. The PCI IRQs are also connected to the MV64361 separately, so the guest could either program the PIC in the south bridge or the MV64361 to get CPU interrupt for PCI IRQs but most guests seem to use the PIC only. On amigaone this is simpler as the interrupt output of the VT82C686B is connected to the the CPU interrupt directly without going through the north bridge (I don't know if that's how the real machine does but since I don't have much info on the ArticiaS this was the simplest way to make it work). But the PIC emulation and the south bridge emulation is shared between amigaone and pegasos2 so they should behave the same. The sam460ex uses different CPU and interrupt controller model so testing that may get different results.
Quote:
I filtered out everything except for the interrupts on IRQ 9 (not easy, as the interrupt numbers used in various parts don't match. I'll check out excp_helper.c, to see if I can find something there.
On pegasos2 everything is configured to use IRQ9 so all interrupts from via-ac97, USB, and PCI cards will raise that. As this makes it quite frequent it's more likely some race condition will happen and since all drivers are on this single IRQ chain if one of them screws up then all other handlers may be affected. The problem may be there on amigaone too but since these are mapped to different interrupts they may not happen that frequently. I think adding a logging handler to the chain in AmigaOS might be the best way to debug it. You could even move that handler around to find the driver which stops. Quote:
I don't know what the IMR and IRR registers are supposed to contain. Likewise, I currently have no idea how the OS can check what triggered PPC6xx_INPUT_INT.
These are documented in the i8259 PIC docs. Interrupt Mask Register and Interrupt Service Register. AFAIU interrupts with 1 bit in IMR are masked out, and 1 in IRR means the interrupt is raised. If the OS gets an interrupt it should check the PIC to know which IRQ it is then check each device configured to use that IRQ to know which one wants attention. Quote:
I'm also still wondering if interrupts are level triggered, and if so, is it being emulated correctly (and how could I check that).
AFAIK the Edge/Level trigger is set by the ELCR register (or the LTIM bit in some global control register but AmigaOS does not touch that).
I've tried running with -bios pegasos2.rom -trace enable="pic_io*" and see what the PICs are set using the info pic command in the monitor. All PIC regs start out as 0, then pegasos2.rom does some setup:
Configuring Legacy Devices
Initializing KBD... Done.
pic_ioport_write master 1 addr 0x0 val 0x11
pic_ioport_write master 0 addr 0x0 val 0x11
pic_ioport_write master 1 addr 0x1 val 0x0
pic_ioport_write master 0 addr 0x1 val 0x8
pic_ioport_write master 1 addr 0x1 val 0x4
pic_ioport_write master 0 addr 0x1 val 0x2
pic_ioport_write master 1 addr 0x1 val 0x1
pic_ioport_write master 0 addr 0x1 val 0x1
pic_ioport_write master 0 addr 0x1 val 0xff
pic_ioport_write master 1 addr 0x1 val 0xfb
Testing 10000000 Bytes, Pass: 00000000 Failed: 00000000
RAM TEST (fill linear)... Done.
and at the smartfirmware OK prompt:
entering main read/eval loop...
ok
(qemu) info pic
Interrupt controller information not available for 7457_v1.2-powerpc-cpu.
pic1: irr=00 imr=ff isr=00 hprio=0 irq_base=08 rr_sel=0 elcr=00 fnm=0
pic0: irr=01 imr=fb isr=00 hprio=0 irq_base=00 rr_sel=0 elcr=28 fnm=0
after AmigaOS starts it programs the PIC on its own:
ok boot cd amigaboot.of
ISO-9660 filesystem: System-ID: "AMIGA BOOT" Volume-ID: "AmigaOS 4.1 Update1 Pegasos2"
Root dir: "^@" flags=0x2 extent=0x31 size=0x800
pic_ioport_write master 1 addr 0x1 val 0xff
pic_ioport_write master 0 addr 0x1 val 0xff
pic_ioport_write master 1 addr 0x0 val 0x11
pic_ioport_write master 1 addr 0x1 val 0x0
pic_ioport_write master 1 addr 0x1 val 0x4
pic_ioport_write master 1 addr 0x1 val 0x1
pic_ioport_write master 0 addr 0x0 val 0x11
pic_ioport_write master 0 addr 0x1 val 0x8
pic_ioport_write master 0 addr 0x1 val 0x2
pic_ioport_write master 0 addr 0x1 val 0x1
pic_ioport_write master 1 addr 0x0 val 0xb
pic_ioport_write master 0 addr 0x0 val 0xb
pic_ioport_write master 1 addr 0x1 val 0xff
pic_ioport_write master 0 addr 0x1 val 0xff
pic_ioport_write master 1 addr 0x1 val 0xfb
pic_ioport_write master 0 addr 0x1 val 0xff
pic_ioport_write master 1 addr 0x1 val 0xfb
pic_ioport_write master 0 addr 0x1 val 0xef
pic_ioport_read master 0 addr 0x1 val 0xef
pic_ioport_write master 0 addr 0x1 val 0xff
pic_ioport_write master 0 addr 0x0 val 0xb
pic_ioport_read master 0 addr 0x0 val 0x10
pic_ioport_write master 0 addr 0x0 val 0x64
pic_ioport_write master 0 addr 0x0 val 0xb
pic_ioport_read master 0 addr 0x0 val 0x0
pic_ioport_write master 1 addr 0x0 val 0xb
pic_ioport_read master 1 addr 0x0 val 0x4
pic_ioport_write master 1 addr 0x0 val 0x62
pic_ioport_write master 1 addr 0x0 val 0xb
pic_ioport_read master 1 addr 0x0 val 0x0
pic_ioport_write master 1 addr 0x1 val 0xfb
pic_ioport_write master 0 addr 0x1 val 0xef
pic_ioport_read master 1 addr 0x1 val 0xfb
pic_ioport_write master 1 addr 0x1 val 0xfb
pic_ioport_write master 1 addr 0x0 val 0xb
pic_ioport_read master 1 addr 0x0 val 0x0
then this repeats a lot as the IDE for the CD and maybe timer or other sources generate interrupts, at some random point later I get
(qemu) info pic
Interrupt controller information not available for 7457_v1.2-powerpc-cpu.
pic1: irr=00 imr=6d isr=00 hprio=0 irq_base=08 rr_sel=1 elcr=00 fnm=0
pic0: irr=01 imr=f9 isr=00 hprio=0 irq_base=00 rr_sel=1 elcr=28 fnm=0
(qemu) info irq
IRQ statistics for 7457_v1.2-powerpc-cpu:
2: 187
4: 1778
7: 15
8: 560406
10: 1294
73: 4
IRQ statistics for isa-i8259:
0: 450
1: 7
2: 1776
12: 1
15: 1775
Don't know if it's any help but just to show how to debug this in QEMU and how you can check the PIC state and interrupts. I think it would be easier to debug it from the AmigaOS side as I think if you get an exception for the interrupts then the problem is not in emulation but in the handlers on the AmigaOS side.
balaton wrote:@Hans You said interrupt handlers are in a list so you could add a handler as the first element that always returns false but logs the interrupt, then you should see when the handler chain is called. If your driver later in the chain does not get an interrupt but you get the log from the first handler in the chain then something inbetween swallows the interrupt.
Another maybe obscure sounding possibilty would be for the interrupt handler to somehow disappear from the system's interrupt handlers list. Sounds crazy and depends on how AOS4 does certains things internally, but I remember early AROS native x86 versions having had a bug where Exec tasks (not interrupts) could misteriously disappear from the System (no longer in any of taskready list, or taskwait list, or thistask).
If OS4 during interrupt handling were to temporary modify interrupt handler list (maybe temporarily remove handler it is going to call) and there's something unexpected happening (nested interrupts?) which it maybe thinks it has protected against, then things like Remove() on an already removed list node can cause funny things (like in AROS disappearing tasks).
I'm no AOS4 coder, but to debug this maybe periodically check the system interrupt handler list to see if your interrupt node is still in there. If you don't know the system interrupt handler list address (maybe in AOS4 it's hidden, not in ExecBase) it should be possible to find it out like this:
Disable();
node = (struct Node *)interrupt;
while(node->ln_Pred)
{
node = node->ln_Pred;
}
list = (struct List *)node;
Enable();
@Hans I've re-read your first post and you wrote that you've set your handler to highest priority so it was basically do the logging I was suggesting but found you got no interrupts even as first handler. Then checked the PPC manual to see what could disable interrupts and found there's an MSR[EE] bit that can mask it out. There's also a comment in the manual: Quote:
Asynchronous, maskable exceptions (such as the external interrupt and decrementer) are enabled by setting MSR[EE]. When MSR[EE] = 0, recognition of these exception conditions is delayed. MSR[EE] is cleared automatically when an exception is taken to delay recognition of conditions causing those exceptions.
I don't quite get what does that mean but maybe when the CPU calls an exception handler it disables further interrupts and something needs to enable it. Don't know if rfi does that or needs to be done explicitly but you could check that this bit is not masking out interrupts and where it would need to be enabled/disabled. I don't think emulation is completely broken, it's more likely something in AmigaOS does something that leaves the system in an unexpected state. The CPU register values can be checked in QEMU monitor with 'info registers' any time.
...then things like Remove() on an already removed list node can cause funny things (like in AROS disappearing tasks).
Why do you keep mentioning AROS and/or AmigaOS <= 3.9 bugs in AmigaOS 4.x related threads?
ExecSG isn't based on any AmigaOS 0.1-3.9 nor AROS sources, it's an independent, about 90% compatible, reimplemation of the exec API.
For example IExec->Remove() in the debug kernels sets ln_Pred and ln_Succ to something like 0xCCCCCCCC. Not sure about the actual value, and it may be different on different hardware, but in any case it makes the 2nd IExec->Remove() of the same node from a list crash with a DSI exception. That way broken software removing a node more than once from a list doesn't cause "funny things" like on AROS and AmigaOS <= 3.9, on AmigaOS 4.x you get a DSI exception with stack trace for such bugs instead.
I don't quite get what does that mean but maybe when the CPU calls an exception handler it disables further interrupts and something needs to enable it.
I probably remember something wrong since it has been about 20 years ago already since I worked on such low level, HAL parts of the kernel, and I only worked on the 603(e)/604(e) parts (classic Amiga with BlizzardPPC or CyberStormPPC), but if not it may work like that: 1. The kernel gets an IRQ, or rather the PowerPC CPU exception caused by external IRQs, and changes the MSR register to disable further IRQs. 2. The kernel calls the interrupt handler functions in the matching exception/IRQ list, until one of them returns TRUE. 3. The kernel re-enables the external IRQs again by restoring the previous MSR value.
That way broken software removing a node more than once from a list doesn't cause "funny things" like on AROS and AmigaOS <= 3.9, on AmigaOS 4.x you get a DSI exception with stack trace for such bugs instead.
It would surprise me if everthing (like in speed critical kernel/Exec parts) in AOS4 always goes through official functions (like Remove()) - if there is one - and never does something by hand or through macros to avoid function call like even oldest 68k Exec used to do. Really??
It would surprise me if everthing (like in speed critical kernel/Exec parts) in AOS4 always goes through official functions (like Remove()) - if there is one - and never does something by hand or through macros to avoid function call like even oldest 68k Exec used to do. Really??
There are no node/list macros used like the ones which were in the old AmigaOS/m68k includes, nor any node/list assembler code in ExecSG, everything calls the exec node/list functions like IExec->Remove(). You could check it by using "debuglevel=20", which makes the system unusable slow or even completely fail at some point because of timing issues (at least if you are using a serial terminal for debug output and not the RAM debug buffer), but includes at least 2 debug messages for every single exec function called: Function entry and exit with result code.
Only the debug kernels (you have to use Kickstart/kernel.debug instead of Kickstart/kernel in the Kicklayout) include such debugging code like setting ln_Pred/Succ to an invalid address in Remove() to be able to detect bugs like double Remove(), the default, non-debug kernels don't, which is faster but you can get the same "funny things" like on AmigaOS <= 3.9 and AROS. Of course developers and beta testers are always using the (slower) debug kernels.
I was a betatesting with a Pegasos II and i am sure there was a few others. I don't remember any problems but i can be wrong, it was a long time ago. It was more stable than my AmigaOne XE.
For users with an OS4Welt.de Account: Please Test the beta RTL8139 driver from https://os4welt.de/viewtopic.php?p=49306#p49306 works if you are using QEmu. Looks like the author of the AmigaOS 4.x RTL 8[01][23]9 drivers found a workaround for the QEmu problems. It looks like it's not sure yet if it's bug in the QEmu emulation, or the AmigaOS 4.x drivers, but the combination of both failed with older versions.
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
