-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interrupt handling on QEMU < 1.2.5 #3
Comments
So, it looks like the root cause is that the jump table for the different IRQ handlers isn't being set up properly in the earlier versions of qemu. on qemu-1.10:
while on qemu-1.30:
If I manually set $r1 in qemu-1.10, things function normally. So now i just need to figure out why there's nothing in the table at 0x10140000. |
This is looking more and more like a QEMU bug. I've checked to make sure that the interrupt vector table is being filled properly -- and it is. We just seem to be getting
|
Good work. I guess we could build out on qemu for the cs machines? On Feb 3, 2013, at 2:00 AM, David Larsen [email protected] wrote: This is looking more and more like a QEMU bug. I've checked to make sure that the interrupt vector table is being filled properly -- and it is. We just seem to be getting 0 back as the address for the ISR. 14c126b from the QEMU project seems to be a fix for this. It looks like it's an off-by-one error. I'll check to see if that is the cause of our errors by adding handlers for IRQs 3 and 5 (since IRQ 4 is our clock IRQ). — |
Hmm... I can get a newer version of QEMU to work on glados without much trouble, but I might be able to get a decent work-around into XINU. I feel like having a work-around might be worthwhile since this bug was only recently fixed. I'll have to look into how much time a workaround would take. @jsb2092 Can you get the quota for the course account bumped up an extra ~500MB to hold a newer QEMU? In the meantime, I'll add a panic() if our ISR handler is |
On older version of QEMU, XINU seems to restart as soon as interrupts are enabled (i.e. as soon as you press the @ key). I thought that this was a QEMU bug for a while, but I haven't been able to find any discussions of anyone else having this problem.
You can test this out yourself with the qemu-system-arm on glados.
The text was updated successfully, but these errors were encountered: