RTC interrupts stop after my first IPI

[eryjus]

How can I tell Bochs to generate more data about the interrupts?

In your .bochs.cfg file, modify the following line to look like this:

Code: Select all

debug: action=ignore, cpu0=report

[kemosparc]

Hi,

I got it working on Bochs. Simply I set the RTC frequency through output to port 0x70 after every time I send the IPI.

But on qemu, it does not work !!

Any ideas?

Thanks,
Karim.

[Brendan]

Hi,

Simply I set the RTC frequency through output to port 0x70 after every time I send the IPI.

Silly hacks like that are never a valid solution. You need to find the actual cause of the problem (which may just be a previous silly hack that you've forgotten about now).


Cheers,

Brendan

[kemosparc]

Okay,

I have removed the flag --enable-kvm from qemu and the RTC works like a charm.

How can I make it work with --enable-kvm ?

Thanks,
Karim.

[Brendan]

Hi,

I have removed the flag --enable-kvm from qemu and the RTC works like a charm.

How can I make it work with --enable-kvm ?

So, you've tested on 3 different virtual machines (Bochs, Qemu+KVM and Qemu without KVM) and it doesn't work on 2 of them.

Don't forget that you may have a bug that depends on timing (e.g. where something may occur either before or after something else), where a slightly faster or slightly slower CPU makes a difference between "doesn't work" and "seems to work but only because you're lucky".

Please note that I've looked at the code you posted previously, and there isn't a single line where I can be 100% sure that I know what it actually does - it's all "abstractions hiding things I need to see" (and C++ is inherently worse, as things like pre-processing and operator overloading mean that I can't even assume "int foo = 1 + 2;" does what I expect without carefully examining every single file).

For a simple example (the very first line of the very first method, in "RTCTimer::fire") what the does "v->setPosition(50,23);" actually do? The object "v" isn't even defined anywhere (that I can see). Does it mess with IO ports? Does it switch back to real mode to change the VGA cursor position? Does it just set some variables? Can 2 different CPUs call "setPosition" at the same time safely? If 2 different CPUs can call "setPosition" at the same time safely, how is that safety achieved (spin-lock? atomics?) and is it actually correct?


Cheers,

Brendan

[kemosparc]

Hi,

No, actually it works perfectly on Bochs and Qemu without --enable-kvm, but does not work when I use --enable-kvm; so it does work on 2 and fail on one.

Okay, originally it did not work on any of the above, but I have worked on the code and did some incremental updates, and the main fix that made it work on Bochs and Qemu without --enable-kvm, is that I used to enable the PIC before starting up the APs, so I have moved this code to execute after starting up the APs and this did the trick; while I am playing around with the code as I said in one of my past replies within this post, I used to reinit RTC after each IPI and this fixed it on Bochs only, but I have removed that and applied the other fix which is starting the PIC after starting the APs.

I had to enable the RTC before starting the APs because I used the RTC counter to wait for the INIT IPI and ISIP, but I have implemented the wait function to read directly from the CMOS to be able to withdraw the initialization of the PIC prior to starting up the APs; although this has one drawback which is the minimum that I can wait is 1 second.

Regarding your question about the v->setPosition it just sets 2 private data members x_pos and y_pos of the object v which is of type Video, and this v is declared local to the RTC, and the RTC fire method is invoked as an interrupt handler and hence interrupts are disabled, so this code cannot happen to execute concurrently especially as the RTC is only configured on the BSP.

Thanks,
Karim

[Brendan]

Hi,

No, actually it works perfectly on Bochs and Qemu without --enable-kvm, but does not work when I use --enable-kvm; so it does work on 2 and fail on one.

Okay, originally it did not work on any of the above, but I have worked on the code and did some incremental updates, and the main fix that made it work on Bochs and Qemu without --enable-kvm, is that I used to enable the PIC before starting up the APs, so I have moved this code to execute after starting up the APs and this did the trick; while I am playing around with the code as I said in one of my past replies within this post, I used to reinit RTC after each IPI and this fixed it on Bochs only, but I have removed that and applied the other fix which is starting the PIC after starting the APs.

No, actually it probably doesn't "work" on anything (and only gives the illusion of working on some systems sometimes).

This is like watching a 4 year-old child poking a dead cat with a stick. You have no idea what is wrong, so you're just doing random things. Some of these random things make differences, but you have no idea why they cause differences or if the problem is fixed or if the symptoms were merely temporarily hidden (and your "fix" just made things worse).

Regarding your question about the v->setPosition it just sets 2 private data members x_pos and y_pos of the object v which is of type Video, and this v is declared local to the RTC, and the RTC fire method is invoked as an interrupt handler and hence interrupts are disabled, so this code cannot happen to execute concurrently especially as the RTC is only configured on the BSP.

Regarding my ~6 questions for one line of code; do I need to post ~6 questions for every other line of code too?

At this stage, my best guess is that whatever you're using to actually print to the screen is not re-entrant, and is called by interrupt handlers on the same CPU in addition to interrupt handlers on different CPUs; and everything you've done has only made it less likely (or more likely, or "differently likely") that the same (non-reentrant) piece of code is being used by multiple caller's at the same time; and there never was a problem with the RTC itself in the first place.


Cheers,

Brendan

[kemosparc]

Thanks a lot for the reply.

I will investigate my code more and will let you know.

Thanks
Karim.